العلاقات

 

عرفنا أن الجداول هي انعكاس للكائنات في الحياة الواقعية، وأن هذه الكائنات يتعلق بعضها ببعض، والمفاتيح الأجنبية هي الوسيلة التي نعكس بها هذه العلاقات في الجداول. بقي أن نشير إلى أن هذه العلاقات على أنواع اعتاد الناس على تقسيمها من حيث عدد الكائنات المساهمة في العلاقة (الصفوف) من الطرفين (الجدولين) إلى ثلاثة أقسام، نمر عليها بإذن الله سريعاً فيما يلي.

 

 

علاقة واحد إلى واحد (one-to-one (1-1 بين جدولين: وتعني أن لكل صف في الجدول الأول، هناك على الأكثر صف واحد فقط في الجدول الثاني يرتبط به. بلغة المفاتيح، هذا يعني أن المفتاح الأساسي في الجدول الأول إذا وجد في الجدول الثاني كمفتاح أجنبي فإنه لا يتكرر أيضاً. هذا النوع من العلاقات نادر في الحياة العملية؛ تخيل جدولين يقابل كل صف في الجدول الأول صفاً واحداً بالضبط (أو لا صف) في الجدول الثاني. من الممكن جداً إلصاق أعمدة هذين الجدولين وإنشاء جدول واحد بصف طويل. لاحظ أن المفتاح الأساسي في الجدول الأول، هو نفسه المفتاح الأساسي في الجدول الثاني، وهو نفسه يلعب دور المفتاح الأجنبي هنا وهناك. كل هذا انعكاس لحقيقة أن كائنين في الحياة الواقعية، مثلاً كائن مواطن وكائن بطاقة شخصية، إذا ارتبطا بعلاقة واحد إلى واحد فإنهما في النهاية الشيء نفسه، ويشكلان كائناً واحداً خصائصه (أعمدته) هي مجموع خصائص (أعمدة) الكائنين. وجود جدولين بينهما هذه العلاقة يعني وجود نفس المفتاح الأساسي للجدولين.

 

لماذا إذاً قد نجد مثل هذين الجدولين أصلاً إن كان الأمر كذلك؟ نحن لا ينقصنا المزيد من العلاقات وأنواعها، حاولوا اختصار المادة ولا تعقدوها، ليس من الضروري أن تكون هنالك دائماً ثلاثة أنواع... الحقيقة أن ثمة أسباباً أكثر من مجرد تعبئة منهاج قواعد البيانات لوجود جداول بينها علاقة واحد إلى واحد، يمكن ذكر ما يلي:

 

1. قد يحدث أن تكون علاقة واحد إلى واحد تعكس بالفعل ولو نادراً العلاقة في الحياة الواقعية بين كائنين يتم معاملتهما بشكل مستقل أحياناً. مثلاً، قد تتم معاملة البطاقة الشخصية في نظام السجل المدني بشكل منفصل عن بيانات المواطن. بالطبع يمكن دمج الاثنين في جدول واحد، لكن تصميم الجدولين يعكس الواقع بشكل أفضل. قد تسمع بمثل هذا عند النصارى مثلاً، حيث يرتبط جدول الزوج بجدول الزوجة بعلاقة واحد إلى واحد على سبيل المثال.

2. لأسباب تتعلق بأداء قاعدة البيانات، قد تختار فصل جدول واحد إلى اثنين وتربط بينهما بواسطة نفس المفتاح الأساسي بعلاقة واحد إلى واحد، لأن الجدول القديم كان كبيراً جداً أو (هل يتصور أحدكم حدوث هذا؟) يكون عدد حقول الجدول قد جاوز الحد المسموح به في الأكسس مثلاً (255 حقل! ستحتاج لشاشة بيل جيتس المزدوجة لمعاينة أفضل لهذا الجدول).

3. قد يكون السبب في فصل جدول إلى اثنين وربطهما بعلاقة واحد إلى واحد هو السرية. فمثلاً، قد تفصل بيانات الموظف الخاصة في جدول منفصل وتجعل صلاحية الوصول إلى هذا الجدول محدودة.

4. سبب آخر هو وجود بعض العمليات المتكررة (مثل نسخ احتياطي على سبيل المثال) على جزء محدود من الجدول (بعض الحقول فقط)، فيمكن فصل هذه الحقول في جدول منفصل لتسهيل هذه العمليات، ولا تنس طبعاً ربط هذا الجدول بالجدول الأصلي بواسطة المفتاح الأساسي ذاته.

 

الخلاصة أن هذه العلاقة تقتضي وجود نفس المفتاح الأساسي في جدولين...

 

 

علاقة واحد إلى متعدد (one-to-many (1-M بين جدولين: تعني أن لكل صف في الجدول الأول عدداً من الصفوف المرتبطة به في الجدول الثاني قد يكون صفراً أو واحداً أو أكثر، ولكن كل صف في الجدول الثاني يرتبط بصف واحد بالضبط من الجدول الأول. هذا هو نوع العلاقات الأكثر شيوعاً، وعادة لا تجد غيره في تصميم قاعدة بيانات، لأن النوع الثالث من العلاقات كما سنرى حالاً بإذن الله يتم تحويله إلى هذا النوع. لاحظ أن هذه العلاقات تقرأ من الجهتين بصورة مختلفة؛ فمثلاً، العلاقة بين جدول العملاء وجدول الفواتير هي علاقة واحد إلى متعدد، أما العلاقة من جدول الفواتير إلى جدول العملاء فهي علاقة متعدد إلى واحد. هذا يشبه أن العلاقة بينك وبين أبيك هي أنك ابنه، والعلاقة بين أبيك وبينك هي أنه أبوك! هذا ليس لغزاً بالطبع، لسنا في برنامج فوازير، ولكن هذه العلاقات تسمى بالفعل أحياناً علاقات أب-أبناء، لأن الأب قد يكون له ابن أو أكثر (أو ليس له أبناء، وعندها لا أدري لماذا يبقى اسمه أباً، ربما من باب التفاؤل)، أما الابن فليس له إلا أب واحد.

 

لكل عميل فاتورة أو أكثر، ولكل فاتورة عميل واحد فقط؛ كل قسم قد يحوي عدداً من الطلاب، لكن كل طالب ينتمي إلى قسم واحد فقط؛ لكل مريض عدداً من الفحوصات، لكن الفحص الواحد لا يكون إلا لمريض واحد؛ للموظف عدد من الإجازات، لكن الإجازة الواحدة لا تصرف إلا لموظف واحد فقط. في كل هذه الأمثلة نطبق العلاقة بتكرار حقل بين الجدولين، الحقل في جهة الواحد هو المفتاح الأساسي، وفي جهة المتعدد هو المفتاح الأجنبي، وهذا الحقل يربط بين الجدولين من حيث أنه بإمكاننا فيما بعد استخراج فواتير العميل، طلاب القسم، فحوصات المريض، إجازات الموظف، وهكذا عبر تتبع هذا الحقل في الجدولين.

 

 

علاقة متعدد إلى متعدد (many-to-many (N-M بين جدولين: تعني أن كلاً من صفوف الجدولين قد يرتبط بصف أو أكثر (أو ولا بصف) من صفوف الجدول الثاني. الحقيقة أن هذا النوع من العلاقات يحدث أيضاً كثيراً في الحياة العملية، لكنك لن تجده في أي قاعدة بيانات علائقية. العلاقة مثلاً بين الكتب والمؤلفين هي علاقة متعدد إلى متعدد، لأن كل كتاب قد يكون له مؤلف أو أكثر، وكل مؤلف قد يكون ألف أكثر من كتاب. كذلك العلاقة بين الطالب والمادة؛ كل طالب يدرس أكثر من مادة، وكل مادة يدرسها أكثر من طالب. العلاقة بين المشترك والشهر علاقة متعدد إلى متعدد، لأن كل مشترك له استهلاك (وبالتالي قراءة عداد مثلاً) في أكثر من شهر، وكل شهر فيه استهلاك لأكثر من مستهلك بالطبع. لنأخذ أيضاً المثال الشهير للعلاقة بين جدول الأصناف وجدول الفواتير؛ كل صنف قد يظهر في تفاصيل أكثر من فاتورة، والفاتورة الواحدة قد تحوي أكثر من صنف. لا يمكن تطبيق هذه العلاقة بين الجدولين مباشرة لأن وسيلة الربط كما أفضنا هي المفتاح الأساسي في أحد الجدولين، الذي نضعه في الجدول الآخر كمفتاح أجنبي. علاقة متعدد إلى متعدد تعني أن المفتاح الأساسي سيتكرر، وهذا يكسر أبسط قواعد قواعد البيانات العلائقية. مثلاً، إذا جعلنا حقل رقم الصنف في جدول الفواتير للربط بين الأصناف والفواتير، فهذا يعني أننا سنضيف صفاً جديداً في جدول الفواتير مع كل صنف، لكن هذا الصف الجديد سيحمل نفس رقم الفاتورة، في حين أن رقم الفاتورة هو المفتاح الأساسي ولا يمكن أن يتكرر.

 

الحل؟ لا بد لتطبيق هذه العلاقة من كسرها إلى علاقتين من نوع واحد إلى متعدد. عالم الحاسوب مليء باستخدام قاعدة فرق تسد. وهي تثبت فعاليتها في الحقيقة. هذا يعني أنك ستنشئ جدولاً ثالثاً وسيطاً وظيفته هي الربط بين الجدولين. لذلك ننشئ دائماً جدول تفاصيل الفواتير. العلاقة بين جدول الأصناف وجدول تفاصيل الفواتير هي علاقة واحد إلى متعدد، لأن كل صنف قد يظهر عدداً كثيراً من المرات في هذا الجدول، كذلك العلاقة بين جدول الفواتير وجدول تفاصيل الفواتير هي علاقة واحد إلى متعدد، لأن الفاتورة قد تملك أكثر من بند (صنف) واحد. الحقل الذي يربط جدول الأصناف مع جدول التفاصيل هو رقم الصنف مثلاً، في حين أن الحقل الذي يربط جدول الفواتير مع جدول التفاصيل هو رقم الفاتورة. حقلي رقم الصنف ورقم الفاتورة هما مفتاحان أجنبيان، لكن مجموعهما هو المفتاح الأساسي في جدول التفاصيل. هذا يعني أن رقم الصنف يتكرر في جدول التفاصيل لأن الصنف عادة يتم شراؤه في كثير من الفواتير، وكذلك يتم تكرار رقم الفاتورة في جدول التفاصيل لأن هناك أكثر من صنف في نفس الفاتورة، وهكذا لا تستطيع استخدام أيّ منهما كمفتاح أساسي في جدول التفاصيل، لكن رقم الفاتورة مع رقم صنف محدد لا يتكرران معاً؛ كل صنف يظهر في الفاتورة الواحدة مرة واحدة فقط. إذا بدا كل هذا مربكاً فاقرأه مرة ثانية، وإذا كان ما يزال مربكاً فلا عليك، إنه مربك بالفعل في أول مرة.

 

كمثال آخر على العلاقات من نوع متعدد إلى متعدد خذ مثال الحساب والقيد في أنظمة المحاسبة... الحساب (مثلاً حساب الصندوق) يظهر في أكثر من قيد، وكل قيد يحوي أكثر من حساب (على الأقل حسابين: دائن ومدين). لتطبيق هذه العلاقة في قواعد البيانات العلائقية يتم إنشاء جدول تفاصيل القيد بالإضافة إلى جدولي الحسابات والقيود. المفتاح الأساسي في جدول الحسابات هو رقم الحساب مثلاً، والمفتاح الأساسي في جدول لقيود هو رقم القيد، أما المفتاح الأساسي في جدول تفاصيل القيود فهو مجموع حقلي رقم الحساب ورقم القيد، وهما كما تلاحظ مفتاحان أجنبيان لربط الجداول بعضها مع بعض.